-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ui: Always show main navigation Key/Value link #10916
Conversation
Currently there is no way for us to use our HTTP authorization API endpoint to tell us whether a user has access to any KVs (including the case where a user may not have access to the root KV store, but do have access to a sub item) This is a little weird still as in the above case the user would click on this link and still get a 403 for the root, and then have to manually type in the URL for the KV they do have access to. Despite this we think this change makes sense as at least something about KV is visible in the main navigation. Once we have the ability to know if any KVs are accessible, we can add this guard back in. We'd initially just removed the logic around the button, but then noticed there may be further related KV issues due to the nexted nature of KVs so we finally decided on simply ignoring the responses from the HTTP API, essentially reverting the KV area back to being a thin client. This means when things are revisted in the backend we can undo this easily change in one place.
8a346b8
to
246e45a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Test needs to be update to see kvs on navigation. |
4455ac8
to
7b0c3aa
Compare
🍒 If backport labels were added before merging, cherry-picking will start automatically. To retroactively trigger a backport after merging, add backport labels and re-run https://circleci.com/gh/hashicorp/consul/453533. |
🍒✅ Cherry pick of commit cf638ee onto |
* ui: Ignore response from API for KV permissions Currently there is no way for us to use our HTTP authorization API endpoint to tell us whether a user has access to any KVs (including the case where a user may not have access to the root KV store, but do have access to a sub item) This is a little weird still as in the above case the user would click on this link and still get a 403 for the root, and then have to manually type in the URL for the KV they do have access to. Despite this we think this change makes sense as at least something about KV is visible in the main navigation. Once we have the ability to know if any KVs are accessible, we can add this guard back in. We'd initially just removed the logic around the button, but then noticed there may be further related KV issues due to the nested nature of KVs so we finally decided on simply ignoring the responses from the HTTP API, essentially reverting the KV area back to being a thin client. This means when things are revisited in the backend we can undo this easily change in one place. * Move acceptance tests to use ACLs perms instead of KV ones
Currently there is no way for us to use our HTTP authorization API
endpoint to tell us whether a user has access to any KVs (including the
case where a user may not have access to the root KV store, but do have
access to a sub item)
This is a little weird still as in the above case the user would click
on this link and still get a 403 for the root, and then have to manually
type in the URL for the KV they do have access to.
Despite this we think this change makes sense as at least something about KV is
visible in the main navigation.
Once we have the ability to know if any KVs are accessible, we can add
this guard back in.
We'd initially just removed the logic around the button, but then
noticed there may be further related KV issues due to the nested nature
of KVs so we finally decided on simply ignoring the responses from the
HTTP API, essentially reverting the KV area back to being a thin client.
This means when things are revisted in the backend we can undo this
change easily in one place.